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□©scription 

{mm 3 The present invention relates to teleconferencing systems, Mere spsctftesiiy, this the present invention relates 
to a messaging protocol and method! for identifying application cap&feftties for leieconrerenee connections. 

£0002] Teieconferefidng fe Increasing^ becoming a popular application in persona! computer systems. Such sppfi* 
cations typlcaily allow the transfer of audio and video data beiwssn users so that they car: speak and o&arw&e com- 
murtfcate with one another. Such appHc&&or& sometimes also include data sharing wherein various types of data such 

?5 as documents, spreadsheets, graphic data, or ether typss of data, can ba shared and manipulated by all participants in 
the teleconference. Different teleconference applications perhaps residing on different hardware platforms have different 
capabilities. Moreover, a wide variety of features has been implemented In different teleconference applications, and 
the proliferation of different types of computer systems with different: capacities, and different networking media has 
created challenges for teleconferencing, 

& [0083]: For example, for meal teleconferencing applications, it is assur? ?ed that: the sender and the receiver have certain 
minimum capabilities. However, with the wfcte diversity of systems having Afferent computet ion oapaoitle:?, ancTto: addition, 
the wide variety of networking madia, thai: certain systems may not have certain capabilities. For example, the fimi 
system may to a high performance workstation ooupfed to a high performance communication medium whereas a. 
second system: may employ an earlier generation processor, operate at a substantially slower dock rata, and/or be 

& cowplad U> a lower capacity communication msdiom, Osdain network o&psbilHIes such as jntilfesi or oiher op&nkatlson 
features, may not be present in oedain networking media. Thus, h order for some teleconference applications to function, 
the participants in the conference can only operate at the fastest possible configuration provided by any minimum system 
which may participate in the teteconferenca 0? course, this results in certain inefficiencies, especially If both of the 
participants are capable of transmitting In a higher capacity than the system with the least possible capability. 

30 loom) Another Issue in teleconference applications Is the ability of certain stations to participate in more than one 
teleconference. In *§ct< in certain circumstances, multiple individual conferences may be desired to be merged by a user 
according to operating circumstances. Due to the distributed nature of certain networks/during this merge operation, 
certain circumstances may change, That is, that white a single elation is merging more than one conference it is partlo- 
ip&tlng in, a second station at a remote location may further have other operating circumstances changing (e.g., eartic- 

& ipants leaving, entering, or otherwise joining an omgoing teleconference}, and thus, the management of such mcrgmg 
operations becomes unduly bttfriensonra, 

{Mm} Yet another shortcoming of certain prior art teleconference applications is the ability to associate Independent 
data stream with an on-going teleconference. For example, a source participant may desire to provide an additional data 
stream to other participants in a teleconference, "["his addihon&i source may include, hut not be limited to, video, data, 
40 andlo or any other type of data available to the source participant For example, such an additional source may include 
other audio information for a receiver. Other types of data may also be desired to be associated with an on-going 
teleconference, which may be accessible to other participant in the teleconference, Certain prior ad teleconferencing 
applications lack these abilities, 

46 SUMMARY 

According to the present Invention there & provided an automatic method tor adding an additional data stream 
to an agisting communication session comprising: 

identify ing the availability of said additional data stream to an endpoint via a message containing a reference to said 

existing communication session; 

receiving notification ot conformation to connect; and 

establishing communication to provide said additional data stream to said andpolnt, said additional data stream 
bang associated with said existing communication session, 

[0007] Also according to the present invention mere Is provided an automatic method for adding an additional media 
stream to bo associated with an existing media stream comprising: 
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\t\% mWi^y of m$ additional media strem to an sndposrrt via a message contesting a refines tc 
$m easting media stream: 

receiving, from said endpmnt 5 e notification of comirmetlori to conned; mti 
ssts&kh'tng commurasstlon ro provide said additions; madia stream to said sndp&inl 

SRIEF DESCRIPTION OF TH£ Q3AWNGS 

[0008] The present tovem&n is ftustrased by way of example and m Imitation in the figures of the accompany!^ in 
which ftks references indicate similar elements and in which: 

Figure 1 Blustr&tes m example configurate in which v&rtoue erobcxSmeftis of m present invention may &e imple- 
mented; 

Figure 2 shows a typical tsleconfefsnctog display which has bath medte and non-media sources displayed during 
tins course at the tsieoDnfsroncs; 
*s Figure 3 shows a single system In which smbodlro&nte of the prssom Invention may bs implemented; 

Rgure 4 shows an example architect w& of a system employing various embodiments of the present Invention; 

Figure 6 shews a mors detailed view of the conference component Illustrated in Figure 4; 

Figure 6 shows a sequence of a t/picai conference events In s conference component which are issued f» an 

application; 

s& Figure 7 shows a typical sequence ef steps performed for member InHkllifation wftftin ihe conference component 

Figures S - 1 D show lypics! sxchsnges of messages for d^tereni operations. 
Rgnre 1 1 snows a detail of e ftraf ondposm establishing a tsfeoorrferenoe. 

Figure IS shews e science of steps performed in a second endpoint receiving she messages sent from a firs* 
endpolnt during the establishment of a teleconference, 
& Figures 13-55 snow detest of Lf-e msss&gss ir&osmiUed between ©ndpytnte dating various teleconferencing mp\h 

cations 

Figures 26a -26b show the steps taken for performing merge operations, 

Figures 27a and 27b show the conferences before end after a merge operation between teleconferences 
Figures 28a-b show a sequence of steps performed by the conference component during a merge operation, 
30 Figure 29 shows an example of a merged conferences table within a single participant 

Figure 30a- 30o shows a sequence of steps performed for converting: point to point connections to multicast con- 
nections for a teleconference. 

Figures 31 and 32 show the adding of an auxiliary source and the messages during the adding of the source to an 
existing teleconference. 

as Figures 33-3^ show the details of a sequence of steps perf omea within a participant for adding: an auxiliary source. 
Figures 35a - 35b show an example sequence of messages which are sent between a firm endpoint and a plurality 
cf other endpolnts in a networking system, and shoeing various messages transmitted therebetween. 

PMAiLEp.DE^RjPTjQN 

[DCOS] Trie present invention relates to networking systems, more specifically, the present invention describes a 
messaging protocol for establishing and maintaining teleconference connections between a pfcra&y of participants in 
a network; ng system. Applications fortNs include, transmitting application and/or system capabilities between participants 
or potential participants in a teleconference, notifying; participants of a teleconference that more than one teleconference 
*s should be merged, end addition of en euKiiiory date street to an on- going teleconference. Although the pre sen i Invention 
will be described witn reference to certain specific embodiments thereof, esoeoi&iiy, mlh relation to certain hardware 
configurations, data structures, packets, method steps . and other specific details, these should mi be viewed as liming 
the present invention. Various? modifications end other may be made by one skilled In the art, without departing from the 
overaii spirit and scope of tno present invention, 

[0010] A portion of the disclosure of this patent document centsins material which is aubi^ct to copyright protection. 
They copyright owner has no nbjection to the facsimile reproduction by anyone of the patent disdesure, tu> it appears 
in tm Patent ano Trademark Office patent tnm or mcm> but omefw&e reserves m copyrignt rights whatsoever. 
Copyright Apple Oompmr } inc. 

[0011 ] A typical system configuration in which a teleconference may take place is $ti&raietf &s 100 in Figure 1 . For 
a^ample, a first vvcrkstatian 150 may oommcnicate via teleconference with a seoond worfeatation 155. as iiiustnstad, 
Syaiern 150 may include a central processing unli i50c which Is coupled to a display "50d a video Input device 150s, 
snd & scund Input device ISGb, The system 150 msy communicate with over system 165 over networking medium 170 
via n^wcrK connection module 160, 160 may include any number ot network adapters oo^merctally av^able such as 
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usincf fetrtomoi, Token Rsng ? or soy osfter networking $*&nci&rd commercially svai&bio, Mens that network adstpte? 180 
m&y aiso include a wlralesa network adapter whioft al&wa transmission of d&ta between corripoitants without a medium 
1 70. Communication & thus provided via rework adapter 1 65 cQupJ^d io system 1 S§> and bmirectionai communications 
may bo asftabBstod betwaen two systems. System 160 further has a keyboard iSOe and a pointing devto I50fc such 
s as a mouse, track ball, or other device for aBetftag user selections and ueer input. 

£80123 A teleconference dispiay fs shown at 280 at Rgure 2, \t\ implemented embodiments of the present invention, 
ttere Is a soores window, such as 201 f showing a monitor of the icscai media gourca, and ftsre are other media windows, 
such m 202 or 203 for each other user with which a participant is having communication, in the titrated example 
eachofthewind^ 

io teJeconfsrenc^g. \n afcernate smbodimsmts of the present Invention, non-media information such as 204 may also ba 
displayed within the teleconferencing display, As vv^i become apparent in the descriptor fesiow, in add-on to media 
and non-media information, messaging Snforrnaiioo mm also be transmitted between stations, in addition, m auxiliary 
roedte source audio or video information) may be transmitted with a spaced conference. The details of this will 



manting the teleconferencing app«ea£ions and sssotiateti processes to be described here. Although certain of the 
concepts to be described hare wiii be discussed with reference to teleconferencing it is apparent thai the methods and 
f apparatus can be implemented for other app&sstta, such as file sharing, rm t$me data acquisition, or other 
; of app8ea*k>ns which sends data from a first participant to e second participant or set of participants, A computer 

[001 4] A computer system, si for? as workstation, persona! computer or other processing apparatus "t 50c; or 1 55c as 
i in Figure 1 Is Biustreted m more detail in Figure 3. 150c comprises a bus or ether cornmu meatier* means 301 for 
mau'om and a processing means 30£ coupled wish bus 301 for processing information. System 150c 
> a random: access memory (RAM) or ether voteffie storage device 304 (referred to as main memory), 
I lo bus 301 fur slofiou. Mormon a fK j iwfcuctiwg ia be executed by prompt 302. roain memory 304 ste 
mey be used for storing temporal variables or other mt&miedleto infomiahon during execution of instructions by proc- 
essor 302. 1 rtduded in memory 304 du ring run-time may be the conference component module which operates according 

other static storage device 308 copied to bus 301 tor storing static intonation and instructions for processor 302, and 
a data storage device 307 such as a magnetic disk or optica; disk and Its corresponding disk drive. Data storage device 
307 is coupled to bus 301 for storing information and Instructions, 

[8015] System 150c may further be ccupied to a display device adapter 321 such as a cathode ray tube (CRT) or 
' (LCD) coupled to bus 301 for displaying intonation to a computer user. Such a display 321 may 
e be ccupiad tote 301 for the receipt of video or taac 

•her keys may be coupled to bus 301 for < 
to processor 302. An additional user input device is cursor control 323, such as a mouse, a trackball stylus, or cursor 
direction keys, coupiod to bus 30 1 for commute ic&tjng direction information and command seioCvOos to processor 302. 
and for controlling cursor movement on display 321, For teleconferencing applications, system 150c i 
coupled to it: a sound output device 324, a video input device 325, and sound input device 328, along with the t 
D/A {Digital-to-Analog} antiA/U {Analog-to - Digital) convertemfor inputting or outputing media signal hitstreams. System 
1 59c may further be coypied to communication <tevtes 3S7 which la coupled to network adapter 1 60 for c 




[0016] Note, also, that any or ail ot t 
embodimenta, however, it can ba approciated 1 
eooording to iho panjoular jmp^meniation. 

[001 ?] in oris ^mbodimont system 1 50c is one of the App& Compute brand family of pomonal computom mcft m 
the ^aoimosh 81 00 brand persona: computer manufactured by Apple Computer, ins, of Cuport^no, ( 
302 may be one of the PowerPC brand microprocessors manufaciured by Motorola, inc, ot i 
{0018} Hem that the lowing dlsoue^on of various embodimonto discussed herein will rotor spoolf ioaliy to a series 
of routes which ars genaretod in a high ievef programming language (e.g., the C or C^-r pfogmmming language) and 
compiled, linkod, and ihen run as objoot code \v. system 160c during rurs-tsme WiHn main memory 304 by processor 
302. For exampie the objeoi cod§ may pe generated by tne 0* Compter av^abi^ from Symantec. m> of Cupertino, 



[0019] Although s genora! purpose compiiter system has b$en described, it can be appreciated by one sk^ed in tho 
art, however, that the following methods and apparatus may bs impiememod In spaolal purpose hardware devices, such 
asdtoeteiogje davicas, large scale Integ^tsd circuits {L5^}> appiicmion ^pedfio intog^ed circuits (ASiC's), or other 
epsdai;20d hardwars. Tno dosonpnen h$m has aquas application to apparatus having $im;ia? function. 

Figure 4 ifiustratas a p&raiity of processes and/or apparatus whfeh may be opemtlva within system isoc, At 
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46 



the highest level, for exampse, at the highest levei in the ISO'QSI network? nc? ntodes. sn application program » such 
as a feieoonferenoino application, an audie/viseo $etv$r, or a date seiver, communicates wsth conference component 
proves® 400m Reform of .Application Program interface (API) calls, '{^econferencecGrrspon&nUOC allows the application 

can &e transmitted between the first participant system and a second participant system. The < 
will be shown In more ctetatf in Figure S, Conference component 400 communicates with the transport component 402 
by sending MevteT&k messages for othsr teleconferencing stations which are encapsifesc* &nti placed into a form that 
the transport component 402, th$ network component 403, and the system network component 404 can packet&e m$ 
transmit over networking medium 170, Forth© purposes of ths remainder of this disclosure, cartam of she ktovleTalk 
Aps calls and McvleTa&Wssages whlen are transmitted between conference components In a teleconferencing system 
wi;; Pa described in more oetsSL 

The transport component 402 end the networking component 403 provide the necessary operations for com- 
rounfc&tfon over tha pa^cular type of network adapter ISO and networking medium 170 according to i 

t 402 may provide the TCP or ADSP prctcefe and paekettelng t according to t 




[0022] A more detailed view of the conference component 400 is shown in Rgure 5, Specifically, conference 
exponent 400 is shown in two portions 400a and 400b which show input and output portions of the conference com- 
iterated as a separate transmitter anti receiver, each conf erenoe component in the system has both 

component 400a receives video and sound information over medis Input channels SID and 520. The video channel 
component and sound channel cornponeni 504 presem media date at mgufer bttaiveis to sequence grabber 5Q£. The 
raaNkne soond and video cte (hereinafter referred to as Visdia data 0 } are provided jo a source stream director 500 
from sequence grabber 502 which then proves the media messages to the transport component 403, Row Control 
501 -hen kirS the video end sound deta flow trough at en smplementetion-deperfdent rrsKjusmoy. Tha video channel 
component 503, soond channel component: 504, and sequence grabber 502 all are Implemented using prior art products 
such as those commercla^y available (e.g., the QuickTime video channel, sound channel components, and sequence 

inc. of Cupertino, California.) Row control 501 may be i 




upon Dsndvvioth, ano ctiie-r constraints *n tne source oerticioeni system. Toe t 
a sink stream director 510 which comprises a portion of the component 400b of the conference component for receipt 
of me* data from transport component 402, Corresponding flow control 511, video and sound stream players 51 2 and 
513, and compression and soend manner 514 and 315, for output of video steams 530 $nd 540, aiso form part of the 

[0033] The conference components main function is to establish and maintain a bi--dlrectionai connection between 
every member of a conference. Conferencing applications use a pre-established control channel to exchange control 
data tha? is pertinent to the conference, ? nis data msgnt include u'ser Identification Intomne&on or other Information that 

contra* massages by establishing" their own control protocol, T he conferencing opponent fudher esfcabllshea commu- 
nication channels between a first endpolnt end a second endpoint, using the underlying transport component 402, Thus,, 
once a media channel has been established* the conference component uses the transport component 40>fs media 
channel which is provided lor transmission of media and non-media Information. For the remainder of this spptation* 
however, the tocos will be on the establishment of communication between a first and second participant (referred to 
as endpomts) or group of participants which may participate In a teleconference. 

Application Program: interface (API? 



API cate. Tha conference component operates mng an event driven model wherein events pertinent to the application 
are issued to the application program. The application program can than take appropriate action either by modifying 
totems! data structures within (creating a source or s! r%. and/or issuance of appropriate messages ov or the network to 
other connected ^rsc"^ents f orpotsemfei pa^lpants, According to messages reoe^d by the convenes oomponsnt, 

d^oum^nt discussing the API to the confsrencecomponent Is aSsched hereto m Appendix A 
^ [0O2B| A typical series of events whk?n occur after tha establlshmant of a teleconference by the conference component 
in an sppiies&on is ttfos&gtsti In Rgur© 8 as 800, For exampie> upon sn initial desire by an ^p^icaf:ion to enter Insc s 
conference m expressed by an API call) era csii from another pQrtio^ant f a conferenc^raaoy event 601 is generated 
The application mn creates a media source in me conference component (e.g., member A) wnich \$ to provide the 
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conference inrormstion. Subsequent to mat, &ny auxrll&ry media sources rn&y sifSsO be altstched to the msin conference 
at step 810 for a second madia source Then, any members mat &e new to m conference am racogmzed as being 
ready by the receipt of MemfcenRsscty events (e.g v SOS and: i03 of figure 8}. Vm ests&fehss the media sinks such as 
b and c tatrated to Rgure 8. Than, during the teleconference session, a vsrtety of othsr avente 604 may b© Issued 
i> and actsd upon by the conference component. These niay include message events, mode events, incoming events* 
data transmission events., etc.. Msrobers leaving the co nfef encs result In the issuance of ^smbsrTgm^nsted events to 
the sppite&fon program such as 60S or Thus, for *wery MemfcerResdy event tor any member participating in & 
conference, there k a corresponding i^eroberTermlnated event prior to the end of the conference, in addition, the 
auxltety source and the oonferoncs itss-if 5$ terminated via the Auxiliary Terminated evsnt 611 and fte ccflferwce 

and teleconference dam $wm no t Jogger oe transmitted. Any attfflonai clean up operates are then p^formed by the 
application., and the source may be discarded. 

[D038] A typical application 's fnalafteatlon Is shown as process 700 of Figure 7. The application program makes a 

^ applfe^n may cause the conference compon^rtt to set its capability at step 702 If It is different than the defeat. The 
cast to M MTConfersnc©Set^essageCapat?l^l8S N causes me conference component to recall in a store the specific ap- 
plication capabilities wstbin the conference component for the specific conference which are later used during transmission 
of messages to alert redplenfe that the sender application has certain functional capabjSttes prior m the establishment 
of a connection between the sender and the receiver.. Each capability has associated with it a type, version, and "desire" 

a» of the capably, Each desire tor each capab% type may be flagged as: 



1 , optional; 
desired;: 

3, requked; or 

4. a negation 



Tfcsse types of capabilities are incfeJdsd In a cepabtliilee list which is transmllKed to endpoints, as will be described below, 

capab% is one which Is not required that it be exchanged before setting up a conference, however, it is preferred that 
ii is. A "required" cacabi^ty Is one which raqutas that a message be exchanged: before setting up a conference. This 
may Include access control or other messages which are transferred peer to setting up a conference. An access control 

; of a account: number and password prior to the commencement of a tetecon- 
> is a capability which Indicates that the application wishes to query the * 
in the case of a negotiated message capability, the type field associated with the < 
i of infomnafion about the applications prior to the establishment of a conference. Any ether types of 
exchanges which require negotiated information between applications may be set, 

[0027] * Once all individual capacities have been set by the Issuance of "Set Cap&biiitkes* API calls to toe conference 
component at step 702, a member may set its operating mode at step 704. The mode will be contained within a mods 
mask value which is sent Irt the APS caii to the conference component, and moreover, Is included in certain messages 
transmitted from the conference component In the render to the conference component h the receiver. The mode mask 
specifies the characteristics of a conference that me member makes available. Different capabilities modes, and other 
■ in Figure 7 may bs set: for arty number of conference types which are made available by the 




& 1, send medsa; 

2, receive medio; 
3.. shareable; and 
4, jester. 



The *ssnd media* mode ftetg Indicates that the member intends to send media data in its conferences, Most members 
mil want to sand media, however, there will be instances where the member wlii be a receh/e-oniy member, thus the 

in conferencm In the case of a send-only member (e,§, t a server priding a reaRlme video and^or audio source), will 
have the receive media mode flag set to *ofT a numeric vaiue '0'}. The Shareable" mode flag Indicates that the 
member is wising to share the conference media data with nm conference members. Thus, in the Instance of a send- 
only media servo r, the shareable mods hag wo^d be sst Indicating that new members can receive the conference data, 
{mm} Tm *p\mf mode flag Indicates mat oil conference members are ^owed to internet, This wouid allow two-way 
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Q ) raso&s in broadcast type conferences wftarssn ona mamoar sands med>& da*a 10 other conteranc^ members, but 
the individual conference members do not exchange any media dels among themselves. Bach of these mode fi^gs ss 
t a: ma beginning cf a connection (e.g., contained within ?h<§ •fteHor message 1400 m Rg. U). 
By dafauft, the csmfarencs component establishes conferences that are Mhf two -way ms$a date capable 

sJong with the &pprop?1at6 flagis) set, Conference mode settings are stored and associated with a particular conference 
ID I?) the sender's conference osmpensm so ifcai wnen messages are created for that coaferenca ID, the appropriate 
mode flags are iransm&ed along with the inii&i&atfon or other messages sent before any other communications. 

to add-on io the capabilities and mods swings at: staps 702 and 704, a time-out * 
psaced from the member may be set.. The timeout value m men included at the beginning of c 
a conference In order to enable a recipient to determine men the easier will mp tor responses. This aiiows 

certain features to be incorporated into participant conference components such as the smart triggering oi events based 
upon context. For example. If the recipient h receiving a call, but a. user does not wish to take the east at that time, the 
-nee knows the time-out occurs and cm take certain cortex; --dependent action (e.g., forward the call, 

[0031] The application can then invoke an API caii ''Listen for Car which implements steps 708 and 7 :0, At step 70S, 
using the underlying transport to which the system Is connected a high ievei address is registered and published This 
men allows other pctenJiai participants In the system to call the member The registration arid pupation of the address 
fe tm^emeritatjorj^eperident ? depending upon the media to whfch the system is connected. Then, at step 710, the 
conference component waits for incoming caib. 

[0032] The conference component in the member sniers m klie stale wherein Incoming messages, aierts for the 
transport component. API and cafe will be detected and acted upon. Note that the capabilities, mode, find time-out 
valnes are all: nplsonai and: the dsfeuR ssV&igs may be used by the member if none of these functions is required by the 
In the call to the MTOonferenceListen function, the application most specify the networks on which the 
$ willing «o auceptcailSvThecunlerenc^ cempenent p;x>ceeds Umg&ter the member en thuse networks, dc«sg 
r is appropriate In the various network contexts, and sends an mtListenerStatus event to the application to 
specify whether the registration attempt was euxesetui. After listeners are operational if another application desires to 
establish communication with the qapfcation, then an mdneorningCaiiEvem Is forwarded to t 
{0033] Figures 6-10 show examples of the various message exchanges between two * 
e rated by conference component 400 depending upon operating: context, and application calls. Figure 8 ; 
example of a calling sec^ence for selling: up a conference between two endpoints, Upon the commencement of a csll 
from standpoint such asSIQshowmn Rgure8 r and a second endpoint such as 820 shown in Figure 8, a" 
mesescte 802 Is transmitted from the endpont 31 0 to the endpoini 620 if they have been set by the caller. The * 
of ^apaMfe* messages 302 and £12 between endpeint 1 810 end e?u*pc»nt 2 i 
channel has been opened on the transmission medium between the participants in an » 
This identifies the capabilities of each of the sndpolnts : if me capabilities of the application ana desired to be transm Stted 
Once capabilities have baen transmlSed from eac^endpoim, each endpoim fiuiner transmits Hello messages 804 and 

discLtseed betow. The Heiio message is the first step in establishing e conference, and 3 flows conference components 
in different systems to escchange basic Identif ication and mode information .. Subsequent to the exchange of Capacities 
messages (if any), andtne Heiio messages 804 and 814, the enc^olnt 1 810 wishing to eetebllsh the conference sends 
a qqI\ message 806 to endpoint 2 820, Subsequent thereto, if endoolnt 820 desires to engage in the t 
endpoint 1 BI O, it sends a response message 816 to endpoint 1 81 0.. Then, \ 
806 and the receipt of the response message 81 fx a teleconference is then established between endposnt 1 BIO and 
endpmnt 2 820. The detail of the process steps permed within oech endpesmt are discsjsoeci with reference to Figures 
11 ann 12. 

Rgure 9 Illustrates a "Join" protocol process. This is simtiartothe cmn§ process, however, a °Joirr message 
906 is ^nt fo the second endpoint instead of the W message 80S, The details of a Join are discussed with relerenoe 
to Figures S8a-g8o below. 

[803S] Figure 1 0 ill ust rstes the messages exchanged for a terminate message. As illustrated, an endpoint may issue- 
a ierminate maasaga to terminate ateiaoonference No response required tot any receivers. 

Figure 1 1 shows the process .steps perfofmed by a first participant {e.g., endpoim 1 si o} wishing to i 
mm a second participant system (e.g., sndpolnt2820}. First at step 110£> t 
dependent means, accesses the address of the party it wishes to ca^ esther by reference to an internal store, referencing 
e server or other impiemantstion-dependsnt manner. Once this hae been performed, the application invokes the API 
cast MTConferenceCali in order to osil- iha party a? step 1 1 D4. Responsrve thereto, either a fstflsd even? 1106 r 
by the csiter, or s ringing event 1 1 0S whan the caii message has been tran^nmad to the second participant j n t 
ot a ringing event the endpoint can then get the capabilities, mode and the name of me endpoint such as by « 
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the date contaiined m the Capabilities wmmgs anchor ths H^lSo rnossags 814, Any Squired* rormamtesto 
t>etwe#n ths ca^er sf:d rec&ver rn&y siso b6 peifof?ne& f fien, the first sender csn appropriately configure its^tf for the 
second endpofct Ones any necessary message exchange and/or configurations have been performed s« the caller* 
tbsn ths catter ©iifcef recsivs a MsmbsrReftJssci event 11 IS. for axsmpte, if fhe casing member doss not provide tfte 
s necessary access control: subsequent to m m message, on a MemberBeaeiy even? ii 1 6, Also, a raited event 11 06 
can be detected at any time, followed by a Merr&erTermsnsted event 1114, in the ease of a IVSemberRefused event 
m2, then the esnferencg component will generate a, MeroberTefn^nstiSd evens in 4, and a conference fcarroinatsc 
event w^i; theft be Issued indicating the end of The conference. Once capacities hsve fcean obtained, any mqusred 
capab?l$es are checked for at step 1113. Sybssquem thereto, a MsrnbsrReady even? 1118 can be receded by ttm 

meHClngtneconrere^eaist^p^na. 

£80373 As shown In Figure 12, the sequence of steps performed by the receiver is illustrated:, For example, at step 
1 202, the receiver application will defect an incoming call event 1 202. Subsequent thereto, the receiver can then determine 

« enc& The mode can also be checked for at step 1 206. Once this has been clone, then a tlrne^uf check! if any, at 1 208 
can be performed I rt the receiver. Thetlms-oufcheck may be performed, depending upon an applicator JmpternenJatJort, 
by checking the -time-out field shown a* field 1:504 In Figure 15, which Indicates hew long the transmitter wi!! wsii prior 
f» timing out and generating a Cai^alted event in order to terminate the call to this case, according to implementation, 

a» caller or, l&fcing same action, such: m fomnrMg the call to another party. Thus, the emberidtag of the time -out field 
1504, within the initial connexion message "Hells,* provides for certain InteiSgerti features m the potsntta* participant 
of a totacoftferertca. Once any iiroe-out checks, If any, have been performed at srtsp 1206, then at step 1208. Any ;j&er 
Interaction may take place at step 1209. The receiver then Issue e reply at step 1510. The reply may Indicate either 
refusal to mmm the call (e.g., dne to access control, or the participant aJresdy engaging In another conference} r or 

the M:embefTe.nxttoated 1 220 event is issued fo the- application in the case of me member answering, the ^ernberReariy 
event 1218 is Issued indicating that the medium channel i$ open and the conference can commence. 



Conferencing Messages 

[0038] Conference components exchange a n lumber of messages In order to establish, maintain* and terrrfoats con- 
ferences Conference components also send messages that encapsulate user data, that is, the data that is < 

E but prior to * 

assage 1300 o:* an Auxiliary message 1 700. The i 
sends a Hello message 1400 to identity itself* specifically its mode of operation {send media, receive media, shareable, 
or joiner} foilowed by a Gail message 1500 (to set up a conference) or a Join message 1800 (to jo*n to an ongoing 
conference). The remote member sends a Response message 1600 In answer to the Gall or a Join message 1800. 
Once a ccnlerencs Is established, a rnember can combine caiss or conferences by sending a Merge message 1900, 
4* Conference member may send or receive a Terminate message 3300 to end a conference. Connections Initially are 
point-to-point between members of a conference, if the transport medium supports multicast adoresses and more than 
one roemher Is participating In a conference, a broadcast to s multicast aCdnsss can oe used m m optimisation. Tbe 

sltlon tror^pG:!^ 

4$ [0040] AW moaaegos supported In tne conference meceaging protocol are preceded by a 2 -byte character Identifying 
tm rmmzm For example tor a capabilities message shown In Rg Lira 1 3 ? field 1 302 contains a *K \ All f 
are further terminated by a MULL sijoh: as that shown in liesd 1808 of Figure 1 3. Tm Gapabilltlas message 1300 ? 
a potential member to taf; other potential conference members what It can and cannot do In a c 
c?endc this message betore sonoiSng the "Hcfio^ message (1400 of figure i -4) if < 

^ sypportsd. 

Fiafd Sim Valije 

type 1302 kbytes >K 

delimiter 10D4 1 byte 

; Lis; 1 308 i>bhsr^jmerfc) O n bytes 
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i§minm.o? \%QS 1 byte NULL 

capabi istses List 1 308 

The member's capabi&tes. Tbia field is optional If speeded, it contains a list of 
the member's capabilte. An application specifies its capabilities by calling the 
conference component's 
MTConfereneeSetMesesgeGep&bMies function. 



[8041 1 The Capab'iife massage 1300 shown in Figure IS Informs ether potential conference participants about a 
member's capabftttes. These oaps&iit&s re&te directly to messages the member either supports or requires, one 
capability for each conferencing message type th&tths component supports. The messages themselves are defined by 
the type of' applicators the member is running, For example, videophone applications and oh&t Rnes deliver different 
services, and use different messages to do so. M a result, the capabilities e member supports w8i change in tight of the 
appiiceh'on ?hat b participative- in the conference. Entries m the ee.pab&t<es List field may request information from the 
r smote system. By setting an entry's "desires" field (201 0 of Figure 20} mtNegotlete^essageGapebHity f N 5 ), & conference 
member can query tor specific information (e.& about a given component type, such as a codec, hardware/software 
features supported, etc.). The type field can contain the component type value. 

[0042] in response to a negotiated Capabilities message : the remote memberfemnafs a user data message, in response 
to the Capabilities message. Note that this list of desi res may contain duplicate entries and entries with a value of NULL 
To parse Ihls array, a member must determine me array s size. After sending a Capabilities message 1 SCO, the member 
sends a Hello message 1400 to establish a conference. 

[00433 ^ message (e.g , 1400 of Figure 14) is sen; at the start: of a conference by each endpoint The Hello 
message 'sdsnSnes basic capabilitfes of the ssncier and the mode m which 't wsii operate. It contains the blowing: 







Value 


type 1402 


2 bytes 




i\&nimym¥em;oni[) 1404 


1-n bytes 


(numeric) 


£te::mlteM408 


1 byre 


colon 


maK'trnum Version 1408 


in bytes 


(numeric) 


delimiter 1410 


1 byte 


newltoe 


confemnceMode 141? 


1-n hyiea 


(n enteric) 


d&Sntfter 1414 


1 byte 


newline 


name 1418 


vn bytes 


(aiph&numehc) 


delimiter 1415 


1 byte 


new line 


delimiter 1 420 


1 byte 


NULL 



rnfenTiEnWe^^ 



The oldee* version of the conference protocol supported 
by tne sending component 
marimurnVsrsion 1408 

The newest version of the conference protocol supported 
by the sending component, 
conference Mode 1412 

The desired conference operating mede. This hetd 
contains a value that corresponds to the operating mode 
the sender desires for this eonlerence. Appltelcns 
specify their desired mode by a SatMode API call 
[d&cusssd abovei 
name t416 

The name ot the prospectus conference member. This 
name jdentiflasthe entity that wants to join the conference, 
and may represent efther en auxtt&ry dam source or a 
rtew user. AppSteetlons specify a user name by ca$ng the 
MTCenfenecceUr>terrAPi ceiL The auxiliary name Is 
spiffed In a MTAttacmAuxN&ry API cell. 
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[0044] The Heilo message i 400 is fhe first step in establishing a conference, This message allows conference* com* 
points on different externa to exchange basic identification and capability mforms^o^ Before $m$ng a Hsifo message 
140O ;! ^conference corrsporierU ro&y send either & Capabilities 1300 or an Auxiliary mssssgs 1700, Thetypeofrnessags 
sent depends upon tfcs roifctfts rosmbsr anticipates playing In the conference, If tfts msrtbsr is looking to sofo or start: 
a conference the contemner component sends a Capacities- message., ti the roemoer & setting up an aux&ary media 
data source, the component sends an Auxiliary message 1 700. Following this message, the conference component can 
entsr the sail setup phase fey ending the Call message 1500, if the member wants to provide saa auxiliary data soupos 
to an easting conference, or join an exiting conference the component sends the Join message 1800, 

Caii message 1600 of Rgure 15 begins the process of establishing a conference connection between two 
possible participants. This Is akin to dialing a number from a pnone directory. 









rype 1502 


2 bytes 




caliTfiTte-eut 1504 


1 *n Oytee 


(numehc) 


delimiter 1 506 


1 byte 


tab 


ConferencaNafna >60B 


1-n cytes 


(aiphenun 


delimiter 1510 


1 byte 


nevviine 




1 *n bytes 


{alphanun 


delimiter 1 51 4 


1 byte 




terminator 


i byte 


NULL 



The amount of fee the calling component is willing fo 
wait for an anew. This field specifies the number of 
ticks (1 /60 of a second) the calling component will wait 
before decidmg that the call has not been answered. 
Called components must respond within this tto 
period. This val ue may be used by a potential rssponder 
for IsMng some automatic action It the user cfoeenl 
answer before the timeout. 
ConferenceNaroe^SOS 

The conference name, if the caller m establishing a 
e>3nferencs< this ia the name -he caller has assigned tc 
he conference, if the caller is connecting to a conference 
serven the is the name ot the serves conference. 
Applications set the conference name by calling the 
^TConfererjcoGall function, 
caingCoftflQ 1S12 

The caller's unique conference kienftfen This field 
uniquely klentmes the caller's conference endpoint on 
the network. Conference components create 
conference identifiers on bens if of calling applications 
which are unique within the confines component. Gail 
are discusssd with reference to 2200 of Figure 22, 



[0046] The CM message 1500 shown In Figure 15 begins the process of establishing a conference between two 
participants. This message can be used 3n two ways, Rrsl. this message cen create a conference between -we partic- 
ipants, in this scenario, me caller assigns a name <o the conference, so that oJher possible participants may join later. 
Alternatively, this message can request to join & conference mat is maneged by a conterenoe server on a network.. For 
ejcampte, the mrv&r aliew incoming emails, bul the functfen of the server Is to merge the new conference doe to the 
caK with other ongoing conferences., in other words, the server acts exclusively as a "joiner" and does mi supply media, 
dsta. Onoe the call }& ml up, the cafe can begin exchanging user date with other conference participants, 
£0047$ The response message 1600 of Figure 1 8 Is sen! In response to Gail or Join messages 1600 or 1 800. 

Reld Valise 

type 1802 2 bytes % P< 

caff Response 1 S04 ? - n bytes (signedn^ehc) 
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VafiM 

deiinitter 1808 1 byte newfine 

6 ctesSn&tonConflD 1 008 1 -rs bytes (alphanumeric) 

deMfnMer 1610 1 byle naafe 

terminator 1 61 2 1 byte NULL 

call Response 1604 

The result. This field indicates the result of tihs preceding 
K> Call request This field is set to "0* sf iha request was 

SLiccessfuL Qthemiss* it contains en appropriate result 



n 603 

The ether «n($otaf$ unique identify. This field identifies 
* 5 the other participant in the conference. 



4& 



The Response message = 600 allows the caller to determine the success of s Gail or Join request Trie Response 
message 1 SCO Indicates haw the user at the remote system reacted to the cai! (forexernpie, whether the use? answered 
the call). The caiiResponse field 1604 contains the request's result cede. If non-zero, an error occurred end the request: 
was not successful. Otherwise, the destinaitonConf ID field 1 800 Identifies the endpomt with which the ce^er may now 
cof^munscate. 

The auxiliary message 1: 700 a! lows one member to alert the other members of a conference that ti is about to 
provide an au&liary media data source (a source associated with an ongoing conference). This message may bs used 
tfi pises ef the Capatnlfe message 1:300 if a participant Is being alerted abeot the presence of an auxiliary media, 
soc? oe ■„• Tine tr?en tbet sends thss n ses^af^e bo e ^encJEnoj ihe He^o and v> cm ^Vses-t: i^^es 1 and ? SOo s and tnt> n proceeds 
to adding an auxiliary csata source to the conference. 



Field Size 

type 1702 2 bytes W 

parsntConffD 17D4 1 byte 
(alphanumeric} 

delimiter -s 708 i byte newiine 



"1703 ,1 byte NULL 
"pirim^n^DT704 

The member's conference identifier. This 
te\6 identifies the memcers existing 
conference endpcint (the conference 
identifier the member suppled in the C&ii 
message when it: first joined the 
conference). Thisaiiows other conference 
participants to identify the source of the 
auxiliary data within each participant. 

[0049] The Auxiliary message 1 700 informs otherconfemnca participants that a member is about to provide en auxiliary 
conference data source. For artery dafa sources:, this massaga r^piace the Capafeitftss massage during aa?ly Men 
actions, ! ts^ n:8mo8r must send ^his messs^ e<scn confeienc© psrtsc'psni. The rnem&er th^n s&nd$ s hello T4U0 
and a Join message 1 SCO to each participant Other participants then accept the new data source by accomodating 
the doh request 

{0Q§$1 A Join message 1 800 of Figure I B allows a member i:o join en existing conference, given that conference's 
identifier. This message is useful for edding: auxiliary cieta sources to an opting conference, and for merging two existing 
snces. 

Field B\Z0 Value 

type 1802 2 bytes v 

dest:nationCcnf iD 1 804 1 m bytes {stohanumenc) 
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sm value 

1806 1-n bytes 

1810 1 byte 

msmfearUs; 1 81 2 O-n fcytes ffipKimmmc} 

terminator 1S14 1 byte ^ULL 

The femoie erKfs un^ueconfer&nce fcientifier. This field 
Ramifies me conference to join on. 
cafiingConffD 3808 

This field 



f den : i f tf3 a t ha cai jar's co nfe ration eodpa : nt on the 
network. Conference components create corrf&fBft&e 
fdertffcrc Of:; fcehaff d raging stations, if the 
message h adding an auxiltefy media data source, this 

roemhert.is* 1312 

A Eist of other cohere nee parti cipants. This list identifies 
all other known conference p&rtlcip&rrts that are willing 



the Joiner Mode Mask set in thesr conference mode). 
The conference component can connect with each 
participant wfth whom it is not already connected. If the 
messsge is adding an aux^asy (via the Issuance of an 
auxiliary rrssssags 1 700), jhss list contains the endpoint 
identifier of a&ch participant to which the criteria making 
the auxiliary available, it is up to each of them to respond, 

tin the list is followed by a newline character. ' 



J00S1 ] The Join message ' 800 aiio^s a member to add an auxiliary data source to an existing conference or to merge 
two existing conferences- The caller sends this message to each member of the conference in response to a. merge or 
Join request. 

[0052] The Merge message 1 900 of Figure 19 combines two conferences. Recipients of this message connect with 
the listed members with whom they are not already connected. 





Size 


Value 


type =902 


2 bytes 


W 


conferenceNaroe 1 904 


i-n bytes 


(alphanumeric) 




1 byte 




myConflO 1008 


In bytes 


(slphsnurnsnc) 


delimiter 1910 


1 byte 




membeiUstl8l2 


0-n byres 


{alphanumeric) 
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Unique 
idertiifiMthe callus 



This fseid uniquely 
sntSpelnt in the terget 



? behalf of < 

A flat of otherconference participants. This M l 
other current conference participants. This list contains 
the arcipoint identifier of each new | 
This b a list of < 

element in the list followed by a \ 





ences with mors than two pariicipa?it& The c&iter sends this message to each existing oonfersnce member, specifying 
the owtfereoc^s name. Each endpain! sstabslshes corotroin jcettons wltri sny new endpolnts. By convention, ifcssndpoint 
wkfc the higher conference identifier value establishes the connection (to m<M duplicate or missed connections), Mem- 
bens of the conference receive a Join menage 1300 instead of a Gals message 1500 when contacted by each nm 

|0054] A oapebll&es list s uoh as shown in Figure 20 (e.g., field 1 31 6} contains information about the message supported 
by a conferencing application. The list consists of mm or more knee of information; each [ire specifies s single capability 







Value 


type 2002 


4 bytes 


(alphanumeric) 


delimiter 20(54 


1 byte 




version 2006 


kbytes 


(numeric) 


deWt«r2008 


1 byte 


tab 


desires 2010 


1 byte 
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to a unique type 



mm 

ctefirnaer 2012 1 byte 



vsrston 2006 

Massage version mimber Specifies the mosKecen* 

ro version of the? 

desires 2010 Support tare*. Tfcis Held i 
level of support required by the application, i 
values are: mtMessageQptionalCapabllity 
Optional, indicates that the message is optional The 

as vakie corresponding to this option is *0\ 

mt^essageDesiredGapebi% 
Desired, Whsie still optional this vaSue indicates that 
the application prefers to receive this message early 
in thecal (e.g. pilar to establishing a call, one member 

for lorie^temi storage}. ?he 
this option jatr. 
miklessageRequfrsdCapabifity 
Required. The appiieafcon must receive this 
as The vsiue corresponding to this option is : R\ 



Negotiate. Trie application wants to learn about the 
recipient's facilities, The vslue corresponding: to this 
option is >D\ 

Conference Identifiers such as 2200 shown in Figure 22 Liquefy identify a, conference endp»i Each and 
point represent a date source or sink forth© conference. Note the* a single system may have more then one conference 
endpofot (e.g., an auxiliary) in a given conference, and may have more than one conference at a time. A conference 
endpoint consists of the following fields; 

Raid Size Value 

U'ViqualD 2202 1 -n bytes (numeric) 
separator 2204 1 byte space 
name £208 1 -n bytes (alphanumeric) 

1^1*10 2202 ' ^ ~~ 

Unique numeric Identifier This field contains a 
unique numeric endpoint identifier, Each 

within the context of a given name specified in 
the namoSeid 2206. 
•wne 2206 
A unique nam* 
network, Trie nemo Is unique ^ 
of a given transport interface, it includesths type 
of the setected transport end network interface. 



A member M such as 1 St 2 of Rgura 21 Is an army of zero or more conference identifiers 21 02, 21 1 0, etc, 
Each entry in the array is delimited by a newfe character, 

[S0S7J The Terminate message 2300 of Figure 23 ends e conference, dosing a members communications with tfte 
participants tc wnich. & sends trie message. 
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Fiesti Sim Value 

type 2302 2 bytes T 

delimiter 2304 1 byte n&wine 

6 terrofoatot-2308 i byte NULL. 

Ths TQrrni?*sf& message 2300 is the last step in ending & member's participation in a c&ftfer&ncs. This message 3rds 
the members conference communication with s$! pantcipants to whioh It sends t^e message, if a member is leaving a 
conference altogether; it must serad this message to each conference pa&§c£p$ftt 

|80S8J The BroadcastRsquest message 2400 a Howe a member to find cat if another conferences member can aecopt 
broadcast {muitteast} messages. 

is type 2402 2 byte f B' 

subtype 2408 1 byte 'TV 

delMer £40& 1 byte tsb 

mfcitesfAddress 2410 1 m bytes 

delimiter 241:2 1 byte newllne 

teffrsfoa£or2414 1 byte NULL 



s±&fpB 2408 

His broacicsst message subtype. This fteici must be set 
to TV. 

mi; itieast Address 2410 

Trie proposed multicast address. This tieid contains the 
m&itost address on which the member proposes to 
send broadcast messages. 



3- [D05§] The BfoadeastRequesr. message 2400 si lows a member to determine whether another conference member 
can aec&pt broadcast messages over a given multicast network address, The reepent sndMes its sb&ty to support 
% by sending: a Brosdc&stAck message 2500 {described beiow). f? the recipient cannot support 

send po?nMo -point messages Jo the recipient. 
m [OOS0] The BfoaotesstReqoest message 2400 ;s typical/ uses as part of the negotiation process that fc stows merging 
two mrtsmmm or the pining of any new members to a conference. As an op*fmb:atiom conference participants may 



£0081] The Bmat&mtAck message 2500 allows a member to respond to a BresdcastRequesi massage 2400. 

40 

Held Stee Value 

type 2502 2 bytes f B* 

subtype 2504 1 byte f & 

delimiter 1 byte tab 

broadcast Response £508 Tn bvtes {signed numeric) 



SO i byte 

terminator 25t2 1 byte 

"sfibtype*2S04 

The broadcast message subtype. This fteid ouist be set to 
W. 

brestostRasponsa 2508 

The rose;!. This field tadfoates whether the member can 
support the multicast address proposed in toe 
BmadcastRequest message 2500. 

E0OS2] The Broadoaet Ack message 2500 aifows a memberto indicate whether it can receive messages overs proposed 
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mij iocast address. Another conference participant proposes § jrtuUfe^st address by sendrng & 8ro&rica$fcR8§yest mes* 
sage 2408, It tne recipient osn support that address, it ssts the oroacieaetRssporisa fiald 2608 to Otherwise tfte 
broadcast Response flaid 2580 corona an appropriate mMsro resuft code, This message is typically used as part oi 
tha negotiation process that follows merging two conferences. As an optimMom conference participants may choose 

s to m up broadcast capabilities as a more-emciant alternative to maiming sever different point-to-point connections. 
Join operations Have the protocol illustrated in Figure 9, Figures 28a-28c illustrate the process steps performed 
tn a transmitter ctmlrecdivef during join operations, Rgure Hfo shows a process which jncluttesftd process steps 
by a transmitter of a join message. This may occur, for sxampte, responsive to an auxsitary or merge message, Rrat< 
the transrrter crests a join roasssge at step 2602. Ths destination conference ID and calling conferred iD's &m 

k> added to the message at step 2603. Then, at step 2S04, all members to rscsiva tfca join message are appended to tfts 
members list in the join menage. This 5s shown in more detail In Figure 26& A srwpon level connection wish the 
memberto receive tha join then performed at step 2605. Subsequent thereto, the message sstfcen sent to any recipients 
a Step 2606 

£0084] Figure 28b i&strstee the "append members* function 2804 shown In figure 28a for appending members to a 
«s member list The function starts at step 2610 which deternlnss whesher the member Is a joiner," If so, then additions! 
members can be appended to the Join.. If not, tfcsn tns function ends, and the join message w&ft the single member & 
transmitted as shown on figure 58a. At £812. the nest member is retried according to the conference iD. At step 2614 
1} \s dmmrnned whether l here are any more numbers irs ihe specified conference ID. If not, the process is compete., if 
there are mere m«T^ers^od the shareable mode flag Is set, as detected at step 2616, then the member Is added to 

members. 

Figure 26c shows the steps performed by a recover of a join message, Rrsj, a! step £652, the dasfination 
conference JD contained in the join message is looked up by the receiver in a locally-stored current conferences history 
*s U&i« 2900 of Rgare Tints kaeps trsack. of previously used oofffewtice ilTs fc-f any uurrenity suiivs oor :fere?icea 
If me inference \0 has chanced, me member can then complete the join by referencing an old conference iD and the 
current oonferenca ID in the member. This allows for conference merge and auxiliary messages from widely distributed 

step 2668, by the issuance of an appropriate response message, ana the join fails. If the conference SO has been found, 
a? mm at step 2680, the connection is added to the list of participants tor the conference. At step 2062, a response that 
lha join can be performed is sent to ma sonde;' of the join. Then, the membership of the members contained in the 
member list of the join can then be petformed as shown in Figure 26d 

[0066] The merge membership function 2604 Is shown in more deteii in Figure 261 First if is determined at steo 2876 
whothor th« m«nb«r merging membership is sharea^e. if so, then at step aUtep 2660, whether there are any more 

at step 2862. ff the participant is already connect, is the member or is the member's own auxiliary source, then the 
pmcoss returns to step 2630. It is determined, at step whether the easing party is going to perform the bin with 
the recipient. This prevents conflicting join messages from being received and acted upon h the network. This Is m- 
compftsfted by determining: whether the recipients conference ID & greaser than the c&iitng party's conference ID. In 
^ thfe case, the calling: party is allowed to receive foe join message and wiil take action on the join. Operations necessary 
to accomplish the join then take place starting at step At th& step, transport level connections are established 
Once established, capafcl!&iS3< If any, (or an auxiliary message, In the case of an auxiliary source), he8o> and join 

ihs conference component Issues ^emberReady to the'appllcation. This process continues until" ail members m\he 
& member list hove been prooossed. 

[SOS?] ^e-rge operations are "mitlated uei ng a ^^ergo* meesage (o&. 1 DOG of figure 1 9} which indicates to a participant 
& that Iwo existing conferences should be merged This Is according to the conference 3D contained within tha fieid 1908 
of Massage 1300. Each Merge message contains within it a meroberUst WVZ which allows the participating members 
to tmnsmit Join messages to m the member ^ which have been l&tetf in ma mem&ertist. This funher ^iowe cftsnging 

and conference membership may be maintained until aftar the ms:rga, A merge operation is gmphlcaliy iliustrated with 
reference to Figures 26a and S8b. Forexampla, first time period 28s, oorjfarenca member ID may be engaging ^ two 
conferences de nosed i and 2 with saverai oiher members. A, B t and C. Coniained within me Ivlerge message having 
the formet \200 ;n Fioars ?9 ? the mombor men pmcsocie to issue Join masssgas to the mamcan-: ot oonfarances. Tm 
\$i member O mum join messages to members 8 and C to join the conference 1 {denoted 8 1 and C^. At the end ot 
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\h& operation msmtos A, 8, 0, and D all have po^nt -to -point communication channels and the nawcoraerancs ID & 
denoted l (A v 8 V C v O v respeotiveiy in aacft or the members}, T'tis frsach&nica ofthia operate sre cteectibed bristly 
with re&srenca to Rgar^ 27. 

» t>8a-28b show the Btsps taken during & merge operation ay the confines component in the transmitter 
; (ft any) or a merge message, Rgure 26a sfcows the process steps t&K<sn by a transmitter of a merge 
. The member first combines the conference ;O r s of the old and flaw conference in ifs internal store at step 2S02> 
Thsn, si step 2804, the mambar creates the nwgs msssags and append aach of tha members of the c^nferancs to 
the members list in the meeeage via the append members routine 2604 {discussed sbove) In order to ensure &8 
connectivity among ail confarsrcoe members, Then, at step 2808. ths rrtgj$3 message & sem to all participants m th% 



Figure 2S& shows process steps taken In a receiver receiving a merge message. Once a merge message has 
been delected (step 2812), the merge recipient res&iss.. In a local siore, the conference name and the conference ID at 
stap 2S14. Then, as discussed with reference id figure 2Sd, above, a merger of member ship Is j 
> is thus complete at step 281 8 ^ 

within each Merge and Join message e Us! of members of the conferences being: merged or joined. These are included 
In the msmbsfU^Mcfe 1812 or 1:912 of messages 1300 or 1900. ?w example, d^etopropag:^bn delays in a networking 
, old conference D's may still axis*: m pariphara! parssaipants, and therefore during merging and or joining opar- 
? ID'S may become invalid, or reference conference D's which no longer exist, Thus. * 

conferences history fabia inlaws a rosmber performing a merge or join operation to determine whether in fact conferences 
to be merged use oid CDnferencs ID f s. If sa then the new conference \D may be liseci to transmit to the parh'dpante 

!) valuer ioa.c^ntajnirlg h vsrkbb te^h list of conference ID's< *e whldi the current 
conference ID refers. Conference entries are deleted &t the end of a conference by the conference component, if a. 
merge occurs at e pe npheral location and e conference ID becomes invalid, then the Hst of conference ID s for en existing 




30 Multicast 



t 0071 ] Figures SOe and 30b teraia a process which ss performed as an optimization if multipb participant within a. 
conference support mu^cesi address broadcast capabilities. First it ie detected at step 3001 whether there ere any 
more transport mectia to be examined. If ec, then me r>sxi Is retrieved at step 3002, and a* step 3003 It denned 
whether two or more pailicipanfe are in the same conference and &re on the seme transport medium, s? so, and the 
transport medium: supports miMasfcs at: step $0D4< then the multitask capabli^es of the transport are activated at step 
30Q& if so, and the rriufest capabilities are working at step 3003, then step 3008 proceeds to step 8012, if it Is not 
working, as detected at step 3006, then the process is aborted et step 3010. At step 3012 a multicast address whbh 
may be used for the transport medium relieved at step 3012. Then, at 3014, Broadcast Requests are sent In sub- 
stantially the format as shown h> Message 2400 of Figure M ; to all the participant detected at step 3002 supporting 
multicast. The process then awaits hro&oeast Acks Cm the format 2500 shown In figure 25) m order to determine whether 
^ 5s available for each at step 301 6 f or if a timeout period eoc^ra. If so, then f or each I 
I to be received at step 331 8, and ft is determined whether the Ack wes positive (due to the ? 
confined in field 2508 of Figure 25). At step 3022, rf the response was positive, then the point-to-point connection is 
deactivated. Onaa- ail the Sroadoaa* Acks have boon reeved (or have timed-cut), then It m determined at step 3024 
whether there was a Broadcast Aok reosiv'cd tor each Broadcast H^cuost message sent, if not. then the procsss is 
compete, 8 so, however, stop 3026 determines whether thsns wers any positive Asks for mo muftfeast It not c then 

Pors (this optimisation cannot bo pcrtormod}.. The process io thus < 



im72] An auxiliary rnedts source can become part of an cngotng cenferonce. Tho modia mwm ;s * 
an ongoing conference by & invoking rafemnes to me main confe^nca stored in eacn oonforonoe component, hovyevar, 
It Is treated as a separate cenfaranoe already in oaoh conferenca oomponant For examp^a, as i^iustrated with reference 
to Figure 31, a first conference refsnad to by confarence ;Q 23B in member 8, may ba notified of an auxiliary sourca 
i^D ^7A from: member A. Nets that sJmtoto the protocol illustrated wth raferancs to tha c 
; in Figures 8 end 9 aoove, the Auxiliary message may ba sent In placa of a < 
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\ a first endpoint end & second endpoint es ikisj rated in Figure 32. The tlrrslny of Fne$sec;e$ \$ illustrated with 
ref srenoe to Figure 32. Sintikr to the capacity ar^d oaa protocol isiustrated with ttferonoe to Rguw 8 afeovo> tfts auxiliary 
message is received from tha first endpotnt 3210, to notify entijx&ti 2 3220 that an auxiliary source is avsiiafcte 
from tfca parent eerfemce ID, as speciffed in psrsntCsnflD flefd 1 70 <s of AuxiBaiy massage 1 700 of Figure 1 7, Then, 
a nm message 3204 is transmitted from andpolnt i 6210 to enctpoim 2 3220, Responsive hereto, encfpoint 2 3220 
trsmnte eapa»ies message 3222 and Hello massage 3224. Subsequent thereto, a Jo*n message 3226 with the 
conference iD » 238 is issued from trie encipoint to 3220 with this confines ID of the source In order to imcm that 
tfcs endpoint 3220 wishes to receive the auxiliary source AA t shown In Figure 31, Subsequent thereto, alt messages 
from source £ to recipient b as Illustrated in Figure 31 reference 1ft® same conference ID 2SB for the ongoing conference 
ba&ve$n a and b. As iilustr&ted in Figure 3 1 , tne *f§c&sve media' rricctefisyj ^ setto not receive ( ! Heceive) sno tuffchsrmora, 
me mode of the aux^&ry soume & not joiner (5Jolner)s!nce it is a receive-only madia source, Subsequent theraso. the 
first endpotnt 3210 sends a responds message 3206 indicating thai the aux$8?y source has been successfully joined 
with the conference 238. Subsequent thereto, both nsedia messages for the conference ID 238.. snd the auxiliary source 

[S073J Figure 33 shows the process steps performed witnln a source of an auxltey source. At step 3302, the next 
participant in the conference to which the auxifissy source will be attached is retrieved It is determined, at step 3304, 
whether there are any more participants in the conference to which the auxfery source will be aHached. i? net then, at 

■tl! step 3304 determines tftsf no addition al participant in tha conference should join in to monitoring 
of ihfr Bifxtlfefy. 

[00743 F W™ 34 shows the steps taken by a receiver upon receipt of the kMm anxlfey message. At step 340?, 
capabiilfe (if any), and hello are sent. At step 3404, the mMmy source medk starts to be received, end the cent 10 
of the pan&m oonferenoe Is saved in the cor jference caEopanent ef Use wc%hn*r at step TOs &3ows ih« apufeiion 
to determine that the anxsliary Is associated with the parent media source by storage m the conference component for 
later retrieval at step 3408, If the aux&ry & received prior to the receipt of & }oin or merge message, then the association 




i (Figures 36a and 35b) 

[0075] An example session using the pratocob described above is shown in Figures 35a and 33b, The figures i : 

s 3502, a 

: tne mouc roasK ^e?. tv »£> uiis - senu, receive, join^i, snar^aDts), 
Than, a calling rr^asag^f is transmitted to the receiver along with the timeout v&iue ^ 19392, Simultaneously with the 
t of the connect, carnsspondlng capabi&5, h*M y and response are sent from the station entitled *i )ii!ary 
i by oackets 3503-3512, having the same mode, 
[COTS] Subsequent to the exchange of capabilities, hello t and cal^ and response, a merge message 3S14 is received 
by the first endpoini including the conference name K Some Conference 0 , e conf ID - 1 37 and a member list The endpeini 
then processes the merge, sending e&pab&ties, and Mio to a member of the ok* conference, and a join aiong with the 
$ shown by messages 351 8, 351 8 ( and 3520, Once the covmexon has been i 
s 3524 and 3S2B are received from the recipient Responsive to the join the recipient sends a \ 
msssags 3523 vvtth the result ^ 0 (request successful). Subsequent thereto, the endpointfhen attempts to use a m^tost 
address by tramming broadcast request messegss 3530 end 3632. The ether members respond with broadcast Aeks 
3S34 and 3536, allowing the use of multicast. Tne oonferenoe can then be temVmateo at any time oy i 
via tne transmission or termtnatfe messages to all of tne rnembem^yoh as 3538 and 3540, 

ferenelng systems, can be eneoled. This inoii^es, but is not limited to, the exchange of oape&iSt&s end notification of 
connections between endpoints } the addition of auxliiary data streems to such cennee^ons, and the merging of existing 
conneot^ne. \tm\\ m appreciated mm mm$h the foregoing nas been described especially w£n reference jo figures 
i "35b. that msny mo-dif^oations rr^sda be made, by one skilled in tne ^rt, without departing rrom the scope of tne i 
. Tne invention is thus to be viewed as iim&ed only by the * 



Claims 

1, An automatic method for adding an additional data stream to m existing cornmunlestion session comp^s^g: 
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identifying the availably of said additional data .stm&m to an endpoim via a message containing a reference 

to said existing communication session; 

receiving notirioation of confirmation to corpses; and 

establishing communication to provide said additional data stream to said ondpoiot ssid addition! data stream 
s being associ&tad with said existing communication session, 

2, The rosthod of claim i , further comprising; 

nstfyirtg s&id andposnt of the dssif& to conned: to proves scald additional data stra&m. 

3, The method of data i whereto said additional oats stream incudes audio information, 

4, The method of claim 1 wherein said additions! data stream include® a second medta connects, 

?s 5. Tha method of da'im 1 whsre'sn said axis£rtg a^m^^ticn sasskm includes a video cornmi.infca8on session. 

£, The method of claim 5 wherein additional data stream indudas an midia source 

7. The method of c&ta 1 wherein sa id reference to said existing communication session deludes a conf ersnce identifier 
£2 of said exiting comrnusVtc&tfEjn session 

8. An apparatus which performs the m&thotf of claim 1 , 

& A machine- readable medium having Instructions stored therein, wn ich when executed on a system, cause the system 
to perform ihe method uf ciaim 1, 

10, An automatic method for adding an additional media stream to be associated with m existing media stream com- 
prising: 

30 identifying the availabit? of said additional madia stream to an endpoim via a message containing a iterance 

to said existing madia stream; 

receiving, from said sndpoint notification of confirmation to connect; and 
essabftshi^com^iynication to provide said additional media stream to said endpoint. 

^ 1 1 * The method of claim to, wherein establishing communication to provide said additional media stream to said endpolflt 
comprises; 

associating said additional media stream in said sndpolnt w£h said existing media stream. 
4Q 12. The method of ofeim 1 0 wherein saki additional media stream Incudes audio information, 

13, The method of claim 1G wherein said additional media stream includes a second communication session, 
14 The method of claim 1 D wherein said existing madia stream includes a video common location session, 
18. The method of claim 14 whorem m$ additional media stream incudes an audio source, 

16, The method of daim 10 wherein said reference $ 3 exiting media stream includes a conference identifier of 
said existing media stream. 

so 

17, An apparatus which performs the method of claim 1 0. 

18, A rnaohina-raada&e medium: having Instructions stored therein, wfc ioh when exsedtad on a system, causa ths system 
to perform tha method of ctafrn I D. 
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